Data handling with clear boundaries.
This page documents how the reference build handles data — published openly, because architecture transparency is part of the showcase. Evidence lives in a dedicated tenant with row-level isolation at the database engine; an append-only audit trail records every material action; AI never finalizes a conclusion. These are descriptions of implemented mechanics in a demonstration platform, not service commitments — no services are offered through this site.
- 01
The platform runs
Sampling, evidence mapping, AI testing, quality review, and exception triage run inside a dedicated tenant, through workflow gates that cannot be skipped. No conclusion auto-finalizes.
- 02
The platform documents
The workpaper + evidence-testing record, with full provenance on every AI determination — model, confidence, evidence excerpts, rationale.
- 03
The auditor concludes & signs
The licensed auditor reviews and accepts or overrides every AI result; no unreviewed AI result can lock a control. The professional judgment is the authoritative gate.
AuditSenior.com (operated by Bonfleur s.r.o.) is not a CPA firm, audit firm, law firm, or consultancy and renders no opinion, assurance, or attestation — the same boundary printed in the exported workpaper's required legal preamble.
Evidence-first determinations, fully attributed
Evidence-first means no mapped evidence yields INCONCLUSIVE, an empty fact value yields FAIL not PASS, and every model is instructed to quote evidence or return INCONCLUSIVE — a PASS without a substantive evidence rationale is auto-rejected. Every AI result carries full provenance — extracted facts with a 0–100% confidence score and per-fact evidence context, rationale, the model used (Claude Haiku 4.5 / Sonnet 4.6; Opus 4.8 for advanced analysis), and evidence IDs. Mandatory auditor review on every result before sign-off.
AI inference: Anthropic Claude API — no model training on customer data, and API-log retention, per Anthropic's commercial-API terms
Where your data lives
Both halves of the stack live in the same US metro: the application runs in Vercel’s US East region (Washington, D.C. area — region code iad1) and primary platform data is stored on Neon in AWS us-east-1 (N. Virginia), colocated so the app and its database sit next to each other. Other sub-processors process transactional metadata in their own operational regions per their published policies. Eight named sub-processors deliver the platform:
| Neon | Managed PostgreSQL (AWS us-east-1, US) — primary platform data, automated point-in-time recovery |
|---|---|
| Clerk | Authentication sessions + user metadata |
| Anthropic | AI inference (see § 02) |
| Vercel | Hosting + platform delivery + transactional log storage |
| Vercel Blob | Evidence-file blob storage, tenant-scoped paths; tenant audit files at rest |
| Pinecone | Content-retrieval index, tenant-isolated namespacing, exact-text matching |
| Upstash | Redis rate-limit + locks — request IPs + user identifiers only; no tenant audit content |
| Resend | Transactional email for contact-form delivery |
This list describes the demonstration platform as presently deployed; it may change as the build evolves.
Hashed, proxied, immutable
TLS in transit (1.2+ per Vercel's platform; HSTS enforced); encryption at rest by Neon (AES-256, per Neon's published documentation). SHA-256 content hash on every uploaded evidence file, surfaced in the Evidence Index. Evidence blob URLs are never exposed in API responses — an authenticated, tenant-verified download proxy serves the bytes. Append-only audit trail refused at two layers — the application role holds no UPDATE/DELETE grant on the audit table, and database triggers reject the mutation for every role.
Engine-enforced, defense-in-depth
PostgreSQL Row-Level Security, session-bound via set_config inside transactions, on all 22 tenant-scoped tables — in FORCE mode, so the policies bind even table-owning roles (defense against ownership drift), not only the application role. Application-layer tenant filtering as defense-in-depth. Composite foreign keys enforce the cross-tenant invariant at the SQL layer. Cross-tenant access returns 404 (not 403) so existence is not leaked. Server-side authz on every entry point; fail-closed middleware.
A control cannot lock until gates clear
Named sign-off gates — testing, QC acknowledgment, AI review, exception closure, traceability, 80% coverage minimum. Hard blockers are separated from informational warnings. Quality review runs 6 control-level checks plus 25 per-sample data-integrity check types (self-approval, segregation-of-duties, post-termination activity, SLA breaches); 8-step workflows (Access / Security / Change) and 9-step (Operations).
Documented, not promised
An internal incident-response runbook exists — severity taxonomy, forensic-preservation procedure, post-incident root-cause documentation — and is exercised as part of operating the demonstration. No uptime SLA, availability commitment, or notification commitment is made: the platform is a showcase operated on reasonable efforts, as-is.
The same architecture could carry a platform for any practice.
Session-bound multi-tenant isolation, append-only audit trail, deterministic seeded sampling, evidence-first AI with mandatory human sign-off, gated workflows. A demonstration — no assurance, compliance guarantee, or attestation, and nothing offered for sale.
Questions about the architecture?
The mechanics on this page are documented in more depth across the platform tour, and questions about any of them are welcome — they create no engagement and no obligation.