Architecture as guarantees. Status as it actually is.
This page lists what the system does by construction, who else touches your data and why, and exactly where compliance work stands. There are no badges here we do not hold.
Architecture as guarantees
Every connection is TLS. HSTS is enabled with preload, so a browser will not downgrade to plain HTTP even on first visit.
The database is Supabase Postgres, encrypted at rest by the provider (AES-256) and reachable only over TLS. Backups are the provider’s daily snapshots. Photographs are analyzed and their findings stored as sealed records; the photo bytes themselves are kept in a private Supabase Storage bucket, addressed by their hash under the owning business, and served only through short-lived signed URLs. If that bucket is not configured on a deployment the photo is not retained at all and the record says so — the health page reports which is the case.
Every price is an integer number of cents computed on the server. The browser never supplies a total. Quotes are immutable versions chained together; every public link resolves to the newest sent version, so a client cannot pay a superseded amount.
Every record carries the business it belongs to, and the database layer refuses a query that forgets to say which business it is asking about. Public endpoints that genuinely cannot be scoped are individually marked with the reason.
When Ciolk produces a result, it stores the exact data and a SHA-256 hash of it with the keys in a fixed order at every level, so the same data always hashes identically. Each day’s records are folded into a Merkle tree whose root is chained to the previous day’s. Deleting a record or inserting a backdated one changes that day’s root, which changes every root after it — the alteration is visible from then on. Verification recomputes from stored data rather than trusting the stored hash, and compares the sealed record count too, because a Merkle root on its own can be ambiguous.
In plain terms: when Ciolk writes a result, it also writes a fingerprint of it. Anyone holding that fingerprint can ask the public verifier whether a record with it exists and whether it is unchanged — and gets back only yes or no, when it was sealed, and which engine produced it. Not the contents, not the name, not the business. The block below is what that request and answer look like.
GET /api/verify?hash=<sha256>
→ { found, valid, integrity: "valid" | "legacy-unverifiable" | "altered", sealedAt, engine }
never: contents, label, which businessRecords sealed before the August 2026 hashing fix are reported as “sealed, but not fully verifiable” — never as a pass. Verify a record yourself.
Access model
Two roles. Owners control billing, settings, integrations and every engine. Employees join with an invite code and see the working surface — schedule, jobs, clients, capture — and never billing or financial reporting. Access checks run on the server for every request that touches business data; the sidebar hiding a page is not what protects it.
Authentication is handled by Clerk (passwords, passkeys and social sign-in with their security controls). Seat counts per plan cover the whole team, owner included. Joining past them is blocked at the invite step with a message to ask the owner to move up a plan; nobody already in is ever locked out, and Sovereign is uncapped.
Your data is yours
- Export: every list — clients, quotes, jobs, invoices — exports as CSV from inside the product. A complete account export is available on request.
- Deletion: on request, your business data is deleted. Sealed hashes (never contents) may be retained so that third parties holding a receipt can still tell a record once existed.
- Retention: active accounts keep everything. After termination, data is retained 90 days for reactivation and then deleted, or sooner on request.
- Training: your data is never used to train AI models. Corrections you make calibrate estimates for your business only.
Full terms in the privacy policy and data processing addendum.
Subprocessors
Every third party that can touch your data, what for, and where. This list is the real one.
| Provider | Purpose | Region | Status |
|---|---|---|---|
| Vercel | Application hosting, edge network, analytics (cookie-less) | United States | Live |
| Supabase | Postgres database — all business records, sealed evidence, leads | United States | Live |
| Stripe | Subscriptions, quote deposits, invoice payments. Holds card data; we never see it | United States | Live |
| Anthropic | Photo analysis, engine narratives and industry-profile generation via the API, under commercial terms — no training on inputs | United States | Live |
| Clerk | Authentication — sign-in, sessions, invites | United States | Live |
| Supabase Storage | Photo bytes, in a private bucket, hash-addressed per business, signed URLs only | United States | Live |
| Resend | Transactional and list email (trial notices, receipts, form confirmations, unsubscribe). The email provider; sends only once a key is set — the status page shows whether it is | United States | Planned |
| Twilio | Telephony for the phone receptionist and, if an owner switches it on, text messages. Configured; the receptionist stays off until enabled per business | United States | Planned |
Payment security
Stripe handles every card. Subscriptions use Stripe Checkout; quote deposits and invoice payments use Stripe’s Payment Element. Both render inside Stripe-hosted frames, so card data never touches Ciolk servers — we receive a token and a webhook, nothing more.
Stripe is a PCI DSS Level 1 service provider. Ciolk’s integration shape is the one that keeps card data entirely on Stripe’s side. We do not claim any PCI certification of our own beyond that, because that is the honest description of what we do.
Webhooks are signature-verified and idempotent: Stripe retries deliveries, and a replayed event cannot mark a payment twice.
Health data
Ciolk OS is not HIPAA compliant today, and we do not offer a Business Associate Agreement.
Ciolk runs a dental or medical practice’s operations — treatment-plan pricing, supplies, sealed checklists, team, proof — without patient records. A CLINICAL account is configured so patient information cannot be entered: quotes carry a reference instead of a name, captures are of the operatory, equipment and supply invoices, and there is no patient list, exam capture or recall until our HIPAA program is live. We would rather say this in plain text than show a badge that ends the company.
- Business Associate Agreements with every subprocessor that would touch PHI — the database host, the hosting provider, the AI provider, the auth provider. None is signed; each is bought only when practice demand carries the cost.
- An isolated database for clinical accounts with row-level security, private storage with short-lived links, and preview deployments that never see it.
- Multi-factor sign-in and session limits for every member of a clinical account.
- A read-access audit log — who viewed which patient record, when — sealed like every other record and exportable to the practice.
- Then a BAA offered to customers, signed in-app and sealed, and only then patient records in the product — in this order: patient records, treatment plans addressed to a patient, exam capture, then claims.
Each step is announced in the changelog when it lands, and the status line above changes with it. No SOC 2 or ISO 27001 certification is held; neither is claimed. Branding never changes a sealed record’s content, and the verify page always carries the Ciolk mark.
- Is a BAA available?
- No. Not today, and not offered on any plan or for any fee.
- Can a practice use Ciolk?
- Yes, for practice operations — pricing, supplies, checklists, team, proof — with no patient records of any kind. The account is built to prevent them, not just to ask you not to.
- What changes that?
- The five steps above, in order, and a founder decision recorded when the program starts. Until then the dental page says so at the top.
Responsible disclosure
Found something? Email noahciolkosz@ciolkoszintelligence.com with what you found and how to reproduce it. You will get a human acknowledgement within 72 hours, a fix timeline once it is understood, and credit here if you want it.
Please do not access data that is not yours beyond what is needed to demonstrate the issue, and give us a reasonable window before publishing. We will not pursue good-faith research.
Breach notification
If we confirm unauthorised access to your data, we notify affected customers by email without undue delay and within 72 hours of confirmation, with what was accessed, what we did, and what you should do. The same commitment is written into the DPA.
Check a record before you trust the page.
The verification tool is public and runs against production.