Compliance & Transparency
The gates every commit passes. The tests every deploy runs.
Kynthar publishes the deploy gates + SOC 2-aligned controls that gate every production change. Not yet SOC 2 audited — the audit is on our 2026 roadmap. What is audited today is the code itself: the gates below run every time.
0 gates. 0 recent commits. All of them pass.
Not a mocked test feed — the live list of scripts/check-*.{sh,py} in this repo, paired with the most recent commits that were merged through them. Regenerated at SSG time on every deploy. When Wave 17e revives the CI surface, this becomes a live feed; until then, the data is reproducible from git.
- Every commit below passed all gates before the deploy script pushed it.
- Scripts are the real pre-commit + deploy gates, not a curated list.
- Regenerated on every deploy — stale data is impossible.
RECENT DEPLOYS
0 commits. All of them passed the gates above.
Read straight from git log at build time — no mocked timestamps, no curated selection. Every row is a commit that actually passed the gate suite in order to ship.
| Hash | Time | Subject | Gates |
|---|
SOC 2 ALIGNMENT
Four trust service criteria. 470 tests backing them.
Not yet audited by an independent third party. What is live: the controls are in place, the tests exercising them run on every deploy, and the audit is on the 2026 roadmap.
| Control | Criterion | Tests | Status |
|---|---|---|---|
| CC8.1 | Change Management | 50 tests | aligned |
| CC7.2 | System Monitoring & Anomaly Detection | 80 tests | aligned |
| CC6.1 | Logical Access Controls & PII Protection | 25 tests | aligned |
| CC7.3 | Evaluation of Security Controls | 315 tests | aligned |
PRINCIPLES
Four principles the gate suite enforces for us.
What the pre-commit + deploy gates mean in practice.
- Automated testing
- Every production change passes the gate suite + E2E tests before the deploy script will push. No human can skip this; the check scripts are wired into pre-commit AND the deploy pipeline.
- Zero customer data in tests
- All test data is synthetic. The E2E fraud scenarios are generated; the auto-improvement loop never sees a real tenant. No privacy exposure from the CI surface.
- Continuous validation
- Tests run on every deployment. Pre-commit gates run on every commit. The schema-refs scanner and envelope-drift checks fire before any SQL or API change lands.
- Full audit trail
- Every AI decision carries the prompt id, model version, latency, and cost via the llm_calls audit table. Tenant-isolated via RLS; every SELECT fingerprinted against app.current_company_id.
DEPLOY PROCESS
Five stages. Every deploy. No exceptions.
- 01
Pre-commit
Every commit runs the full gate suite locally: schema-refs, envelope-drift, llm-types staleness, SubPageCard cap, marketing phase-2. Any failure blocks the commit.
- 02
Regression tests
10 fraud scenarios run end-to-end before deploy.sh pushes. Any accuracy regression below the 85% gate blocks the push.
- 03
Static deploy gates
Six gates fire before push: schema-refs, envelope-drift, wave13 ceiling, wave9 strict, llm-types staleness, deploy-script anti-footgun (32 forbidden host-state patterns).
Commit does not leave local - 04
Server-side deploy
Canonical deploy-server.sh on EC2 handles migrations, live schema check, selective rebuild, rolling restarts, critical-services verifier, API health, warm-cache, nginx reload, email + Postfix verifiers.
- 05
Smoke canary
One scenario runs against production before deploy.sh exits clean. If the canary fails, the deploy is marked failed and the incident process fires.
Touchless when green
470+
Automated tests the deploy pipeline runs.
150 integration / E2E scenarios + 320+ unit tests, cross-section. Every production change passes the full suite; a single failing test blocks the commit.