Trust Center
Security evidence buyers can review without a founder on the call.
Tenant isolation, RLS proof, backup readiness, audit logging, sub-processors, AI data handling, and incident response in one honest buyer-facing package.
Controls
What IT, finance, and operations teams usually ask first.
Data residency
Customer Data is stored in DigitalOcean's Singapore region (SGP1): the database, uploaded files and backups. Sub-processors are as published on the list below.
Tenant isolation
Application tenant filters are backed by PostgreSQL row-level security evidence for tenant-scoped tables.
RLS proof
RLS coverage matrix, app-role checks, and runtime cross-tenant isolation tests are part of the Postgres parity gate.
Backups and restore
Restore drill runbooks define Alembic parity, tenant isolation smoke, RPO, and RTO evidence expectations.
Audit logging
Security-sensitive and business-critical actions are recorded in tenant-scoped audit events where wired.
AI data handling
AI is positioned as tenant-scoped, minimum-context, advisory assistance with human confirmation.
Review documents
Downloadable diligence notes for serious buyers.
These documents make security, backup, AI, incident, and data residency review easier before procurement asks for a formal pack.
Security architecture
Security architecture review note
A buyer-level map of access, application, data, integration, logging, and deployment controls to review before production.
Review status: Operational security draft. Confirm final controls, legal wording, and customer-specific commitments before contract signature.
Backup and restore
Backup and restore policy
Operational backup expectations, restore drill requirements, and evidence buyers should request before go-live.
Review status: Backups are daily on DigitalOcean managed PostgreSQL in Singapore, kept 7 days with point-in-time recovery. Deletion and backup expiry are in the published DPA (clause 3.6). RPO and RTO are measured, not quoted commitments.
AI data handling
AI data handling policy
How AI features should be scoped, reviewed, and governed when connected to tenant-specific ERP data.
Review status: The AI providers, the data each receives and where it is processed are on the published sub-processor list. A workspace limits or stops what reaches them in Settings > AI Agents.
Incident response
Incident response process
The severity model, containment workflow, customer communication expectations, and post-incident review path.
Review status: Breach notice within 72 hours is committed in the published DPA (clause 3.5); first-response targets are in the Terms (section 6.4).
Subprocessors and residency
Subprocessors and data residency note
Where the sub-processor list is published, what it covers, and where Customer Data is stored.
Review status: The list itself is published at https://api.twentycore.ai/api/v1/legal/sub-processors and shown on the privacy page and in the trust center.
Legal and security review
Legal and security review checklist
A buyer-ready checklist that separates operational evidence from contractual commitments before production use.
Review status: Review checklist. It helps procurement prepare diligence, but it is not legal advice or a signed data processing agreement.
Data processing review
Data processing review note
A structured review of customer data categories, processors, retention, export, deletion, and AI/integration boundaries.
Review status: Procurement checklist. The DPA, the sub-processor list and the hosting region (Singapore, DigitalOcean SGP1) are published; customer-specific terms go in the signed agreement.
Evidence
Linked to real repository artifacts.
The Trust Center intentionally points to artifacts and tests that can be reviewed during security due diligence. It avoids unsupported certification claims.
- tasks/artifacts/rls_coverage_matrix_2026-05-06.json
- tasks/artifacts/postgres_parity_coverage_inventory_2026-05-06.json
- tasks/artifacts/rls_production_deploy_runbook.md
- backend/tests/postgres_parity/test_security_rls_parity.py
- docs/INCIDENT_RUNBOOKS.md
- docs/BACKUP_RESTORE_GUIDE.md
Sub-processors
The vendors that receive customer data.
DigitalOcean LLC
Application hosting, managed PostgreSQL and object storage for uploaded files
Singapore (DigitalOcean SGP1)
Cloudflare, Inc.
Edge network in front of the API: TLS termination, DDoS protection, and the signup bot check (Turnstile)
Global (anycast)
Vercel Inc.
Hosting of the web application and twentycore.ai, and the proxy that carries the application's API requests to DigitalOcean
Global edge network
Stripe, Inc.
Subscription billing and payments
US (with EU/SG sub-processors per Stripe DPA)
Resend
Transactional email delivery
US / global sub-processors per Resend DPA
Sentry (Functional Software, Inc.)
Error monitoring and performance telemetry for the API and the web application
US (EU region available on request)
Google LLC (Gemini API)
AI text + vision generation for tenant-facing AI features
US
LHDN MyInvois (Inland Revenue Board of Malaysia)
Government e-Invoice clearance for MY tenants
MY (Malaysia, government cloud)
Reviewed 2026-09-24. Source: https://api.twentycore.ai/api/v1/legal/sub-processors
Security Review Pack
What a buyer should ask us to prove.
This checklist keeps the sales process grounded. It gives finance, IT, and operations teams a concrete agenda for due diligence instead of relying on broad trust claims.
Identity and access
RBAC, 2FA/TOTP, SSO readiness, user lifecycle, and admin controls
Tenant data boundaries
Application tenant filters, RLS parity gates, and cross-tenant regression tests
Operational recovery
Backup policy, restore-drill expectation, migration evidence, and rollback workflow
Integration risk
Stripe, LHDN, SMTP, object storage, Redis, and webhook configuration boundaries
AI governance
Tenant-scoped context, human confirmation, prompt/data minimization, and audit logging
Commercial handoff
Export policy, cancellation flow, support channel, and implementation responsibilities
AI you can audit
Every AI claim below is derived from source, not written by marketing.
Fixture counts are read from the golden-example suites, SLO and evaluation thresholds from the feature registry, and write-back governance from the live mutation registries. The same numbers are served, recomputed at request time, at /api/v1/trust/ai — and CI fails if this page's claims drift from the code.
3
Supported AI features
exactly this many — CI fails if the registry and this claim drift
191
Golden eval examples
counted from the eval suites at generation time, not typed in
10/10
Undo coverage on AI writes
every executed mutation type has a deterministic reverse path
heuristic · 0 fitted outcomes
Confidence calibration
fitted = the outcomes the curve was fitted on, each customer counting for at most 10 (0 recorded in total); labelled "empirical" only after ≥30 fitted outcomes from ≥3 customers — zero is reported as zero
| Feature | Golden evals | Eval threshold | Contract checks | p95 latency SLO | Model tier |
|---|---|---|---|---|---|
| AI Chat Copilot | 67 / min 50 | ≥90% | not measured — judge required | 6.0s | fast tier (Gemini 3.5 Flash-Lite) for every chat turn; the Business Assistant, the Copilot drawer, AI Support, /ai/ask and Finance Q&A never re-ask on their own — the drawer's and Finance Q&A's opt-in "Check with the stronger model" re-asks a flagged answer on the strong tier (Gemini 3.8 Flash) for 3 credits, refunded when no answer comes back |
| AI Close & Anomaly Copilot | 62 / min 50 | ≥85% | 100.0% contract checks | 5.0s | statistical ML core (IsolationForest); fast tier (Gemini 3.5 Flash-Lite) for explanations, the anomaly narrative and the close variance narrative |
| AI Document Processing | 62 / min 50 | ≥90% | not measured — runtime DB required | 10.0s | strong vision (Gemini 3.8 Flash) to classify and to extract |
These are deterministic contract checks on committed fixtures, not customer accuracy or correction-rate estimates. Features requiring a judge or runtime database remain unmeasured here. Live evaluation and judged production samples have separate denominators; this page does not establish a held-out customer benchmark. Current evidence is served at /api/v1/trust/ai.
Evaluation checks — latest CI run
Evaluation checks against the declared suites, recorded by the CI eval suite and read live from /api/v1/trust/ai. Pull-request and bake-off runs are never recorded here. Deterministic contract checks and model-graded checks are counted separately; the floor verdict uses the model-graded checks of the same run only. These are test-check pass rates, not customer accuracy.
Loading the latest recorded run…
Honest model disclosure
Two-tier Google Gemini stack with a deterministic rule-based fallback. The fast tier (Gemini 3.5 Flash-Lite) serves simple, high-volume tasks; the strong tier (Gemini 3.8 Flash) serves document extraction, multi-step planning, financial analysis, negotiation briefs, cross-system synthesis and intent parsing. Reliability still rests on the scaffolding around the models — eval suites, versioned prompts, faithfulness grounding, per-call token budgets, usage metering and audit logging. Configured model names do not establish measured task quality.
Frontier models: Off by default. An operator may enable an explicit per-call opt-in (use_frontier=True, gated on AI_FRONTIER_ENABLED + AI_FRONTIER_MODEL) so a chosen high-stakes task is served on a configured top-tier model. Nothing selects it on its own.
AI writes: propose → approve → execute → undo
AI never posts money without approval.
The AI never mutates ERP records directly. You can run this exact walkthrough against the live API — a different human must approve, and every executed mutation has a deterministic undo:
- 1. propose — a validated draft is staged as pending_approval; no ERP record is touchedPOST /api/v1/ai/writeback/propose
- 2. review or edit — an approver may amend the draft; edits flip provenance off pure-LLMPATCH /api/v1/ai/writeback/proposals/{id}
- 3. approve and execute — a DIFFERENT human with the per-type approve permission executes it deterministicallyPOST /api/v1/ai/writeback/proposals/{id}/execute
- 4. undo — a compensating action reverses the result (audit-logged; refuses on changed state)POST /api/v1/ai/writeback/proposals/{id}/reverse
Separation of duties: the approver must be a different human than the proposer. Undo: every executed mutation records what it produced and has a deterministic compensating reverse (draft-cancel, reversing journal entry, hold-clear); reversal refuses if a human has since progressed the record.
Snapshot generated from source on 2026-11-01 by backend/app/services/ai/ai_evidence.py --write-snapshot. Live copy: GET /api/v1/trust/ai. Refresh: cd backend && python -m app.services.ai.ai_evidence --write-snapshot ../website/src/lib/ai-evidence.json
Readiness Boundaries
Clear status beats vague enterprise language.
TwentyCore separates what can be reviewed immediately, what must be confirmed during rollout, and what is not claimed today.
Available for review
RLS coverage artifacts, PostgreSQL parity tests, incident and backup runbooks, AI methodology, and security architecture pages.
Confirmed per customer
Data residency, object storage provider, email provider, Stripe/LHDN credentials, SSO setup, and integration-specific scopes.
Not claimed today
SOC 2 certification, ISO 27001 certification, universal LHDN production approval, or customer-specific audit results before validation.
Plain-language limits
What we will not overclaim.
TwentyCore is not SOC 2 certified or ISO 27001 certified today. LHDN production approval depends on customer credentials and authority validation. AI provider behavior must be confirmed per deployment.