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
Southeast Asia deployment design with hosting region confirmed per customer environment and integration set.
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: Operational resilience draft. Final RPO, RTO, retention, and deletion terms require commercial/legal approval.
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: AI governance draft. Provider terms, training-use, retention, and opt-out obligations must be confirmed per deployment.
Incident response
Incident response process
The severity model, containment workflow, customer communication expectations, and post-incident review path.
Review status: Incident process draft. Support SLA, notification commitments, and breach language require contract/legal review.
Subprocessors and residency
Subprocessors and data residency note
Provider categories, data roles, regional assumptions, and what must be confirmed in the final deployment agreement.
Review status: Subprocessor draft. Final provider list, regions, DPAs, and retention terms must be confirmed for each customer environment.
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 draft. Final DPA, subprocessor, region, retention, and deletion language requires customer-specific legal review.
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
Provider categories to confirm before go-live.
Cloud hosting
Application, database, storage, and backups
Email delivery
Transactional notifications and workflow email
Payment processing
Subscription billing metadata and checkout
Observability
Metrics, alerts, and redacted operational logs
AI provider
Optional tenant-scoped prompt context
LHDN MyInvois
Invoice payload submission when customer credentials are configured
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.
Eval counts are read from the golden-example suites, SLO and accuracy floors 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.
7
Supported AI features
exactly this many — CI fails if the registry and this claim drift
466
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 outcomes
Confidence calibration
labelled "empirical" only after ≥30 recorded real outcomes — zero is reported as zero
| Feature | Golden evals | Accuracy floor | Golden-set result | p95 latency SLO | Model tier |
|---|---|---|---|---|---|
| AI Chat Copilot | 66 / min 50 | ≥90% | judge-graded (no single label) | 6.0s | strong (Kimi K2.5); fast tier (Gemini 2.5 Flash) for simple turns |
| AI Procurement Negotiator | 55 / min 50 | ≥85% | judge-graded (no single label) | 8.0s | strong (Kimi K2.5) |
| AI Anomaly Detection | 76 / min 50 | ≥85% | 100.0% measured | 5.0s | statistical ML core (IsolationForest); fast tier (Gemini 2.5 Flash) for explanations |
| AI NL-to-SQL | 77 / min 50 | ≥88% | 100.0% measured | 4.0s | fast tier (Gemini 2.5 Flash) |
| AI Document Processing | 57 / min 50 | ≥90% | measured live — /api/v1/trust/ai | 10.0s | strong vision (Kimi K2.5) |
| AI Vision QC | 63 / min 50 | ≥85% | 100.0% measured | 9.0s | fast vision (Gemini 2.5 Flash) |
| AI Operations Agent | 72 / min 50 | ≥85% | 100.0% measured | 15.0s | strong (Kimi K2.5) for plan + synthesize |
Golden-set results are scored by the same functions production uses and re-asserted against the floor on every build. Judge-graded features report no deterministic number — a rate we cannot measure deterministically is labelled, never invented. Production pass rates vs these floors (and platform write-back counts) are served live at /api/v1/trust/ai.
Honest model disclosure
Cost-optimized two-tier LLM stack with a deterministic rule-based fallback. We deliberately do NOT use frontier/flagship models — reliability comes from eval suites, versioned prompts, faithfulness grounding, per-call token budgets, usage metering, and audit logging, not from raw model capability.
Frontier models: Off by default — the default stack does not use frontier models. 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 the strong tier with a configured top-tier model. Auto-escalation never does this 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-07-27 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.