Built to be auditable. Honest about what we don’t claim.
TinkyTown serves vulnerable populations at public counters — deaf-blind patrons, ESL learners, stroke survivors, the elderly, kids with disabilities. We collect the absolute minimum data needed to make a tile speak the right sentence in the right language. This page is the full breakdown — including the formal certifications we DON’T yet hold. Honest beats optimistic for the people we serve.
What we collect. What we don’t.
This is the most-asked enterprise question, so we lead with it. TinkyTown’s data flow is designed around minimum collection: enough to make a tile speak the right sentence in the right language, and absolutely nothing more from visitors.
What we DO collect Collected
From a visitor (the deaf-blind patron, the ESL parent, the stroke survivor — the person tapping tiles on their own phone):
- Language preference selected at session start (e.g.
es,ar,hmn) - Anonymous tile-tap counts aggregated by venue and tile, never by visitor
- Coarse timing (hour of day) for capacity planning, never to the second
From a tenant (the business, town hall, hotel, bank, hospital that signs up to deploy TinkyTown at a counter):
- Business name + business URL (e.g. "Delamar West Hartford", "westhartfordct.gov")
- Contact email of the ADA Coordinator / GM / signing party
- Billing details processed by Stripe (we never see the card PAN)
- Deployment configuration (counters, languages, board customizations) — the tenant’s own work product
What we DO NOT collect Never
- Visitor names — ever, in any field, on any surface
- Visitor contact info — no email, no phone, no address
- IP-to-identity mapping — Cloudflare sees the IP at the edge for abuse defense, but we do not store visitor IPs in our database
- Biometrics — no face data, no voiceprints, no fingerprints, no gaze data
- Audio recordings — text-to-speech generates audio at the visitor’s device; we don’t capture it back
- Transcripts — what a specific visitor said is not stored on our servers
- Device fingerprints — no cross-session tracking, no advertising identifiers
- Camera / microphone — the kiosk surfaces do not request these permissions unless the venue has explicitly opted into the optional OCR / live-caption add-ons, and even then nothing is sent to our servers without on-screen disclosure
The 2am scenario: if a deaf-blind person taps the "emergency" tile at 2am, all our analytics see is "tile X tapped in venue Y at hour H" — never who they were, never where they were standing, never which phone they were holding. That is the entire point of the design. The most vulnerable people at the most vulnerable moments deserve to disappear into the aggregate.
TLS 1.3 in transit. AES-256 at rest.
Every byte that moves and every byte at rest is encrypted with a current industry-standard cipher suite under managed-service operators (Cloudflare and Vercel) who handle the underlying key rotation and HSM-backed key management.
In transit
- TLS 1.3 terminated at the Cloudflare edge with modern cipher suites (ECDHE + AES-GCM / ChaCha20-Poly1305)
- HSTS enforced on all production hostnames (tinkytown.com, *.tinkytown.com)
- HTTP/2 + HTTP/3 on the edge; TLS-only on workers
- No mixed content — all assets, fonts, API calls served over HTTPS
At rest
- Tenant records live in Cloudflare D1 (SQLite) — AES-256 at rest, managed by Cloudflare
- Session + cache data lives in Cloudflare KV — AES-256 at rest, with explicit TTLs (most entries expire automatically)
- Static assets (HTML / CSS / JS) live on Cloudflare and Vercel CDN edges — encrypted at rest, no customer data on disk
- No plaintext customer data on disk in any system we control
Secrets & keys
- API keys (Gemini, Stripe, Resend) live in Cloudflare Worker secrets — never in source control, never in logs
- JWT signing keys rotated on a documented schedule; old keys retained only long enough to honor existing sessions
- No credentials in git — the repo has secret-scanning enabled at GitHub
What we have. What we don’t.
This is the section other vendors fudge. We will not. Below is the literal list of what TinkyTown holds today and what it does not hold. If you need a certification we don’t yet hold, please tell us during the pilot conversation. We can scope the work and timeline.
What we DO have Held
- State of Connecticut ADA Officer review — Stacey Lumley, Statewide Digital Accessibility Lead, validated TinkyTown for the West Hartford Town Hall pilot. Letter on file. 151 CT municipalities directed to deploy.
- 28 CFR § 35.160 (ADA Title II) effective-communication conformance — the operational standard for public-entity counters. See our Title II walkthrough.
- 28 CFR § 36.303 (ADA Title III) auxiliary aid conformance — the standard for places of public accommodation (banks, hotels, restaurants, retail). See our Title III walkthrough.
- WCAG 2.1 Level AA conformance pursuit — aligned with the DOJ digital accessibility final rule (effective April 24, 2026 for entities serving populations ≥50,000; April 24, 2027 for <50,000).
- Section 504 of the Rehabilitation Act (29 U.S.C. § 794) alignment — relevant to federally-funded entities including hospitals receiving Medicare/Medicaid and federally-funded schools.
- 42 U.S.C. § 18116 (ACA Section 1557) alignment — meaningful-access standard for LEP populations at healthcare entities. See our LEP walkthrough.
What we DO NOT have (yet) Not held
- SOC 2 Type I or Type II certification — not started. We have not engaged an auditor and we do not have a SOC 2 report to share. If your procurement requires SOC 2 before signing, please tell us during pilot conversation so we can scope the timeline (typically 6–12 months for a first audit).
- ISO 27001 certification — not pursued for v1. No plan to pursue in 2026.
- HIPAA formal attestation / BAA-ready posture — PHI does not flow through TinkyTown by design (see Healthcare Posture below), so the HIPAA scope is narrow. But we do not have a third-party HIPAA attestation, and the BAA is not a standard-issue document. For hospitals that need a BAA, we can scope one during pilot conversation.
- FedRAMP authorization — not pursued. No plan for v1. If you are a federal agency that requires FedRAMP, we cannot serve you today.
- GDPR EU Representative (Art. 27) — AgeWell Alliance, LLC is a US-only company today and does not maintain an EU representative. EU-based customers should contact us directly to discuss their data-protection requirements before signing.
- StateRAMP, TX-RAMP, or other state-level authorization frameworks — not pursued. If your state requires one, please tell us during pilot.
- CSA STAR registry — not registered.
- PCI DSS direct attestation — we do not store, process, or transmit card data ourselves. Stripe (PCI DSS Level 1) holds the card-data scope on our behalf. We rely on Stripe’s attestation.
If you need any of the above certifications before signing, please tell us during the pilot conversation. We can scope the work, the timeline, and the cost. We would rather honestly say "not yet, here’s our plan" than fake a badge.
The whole supplier list. Nothing hidden.
Below is the literal list of every third-party service that touches TinkyTown infrastructure or tenant data. If we add or change a subprocessor that handles tenant data materially, active tenants receive a 30-day email notice before the change takes effect.
Cloudflare
Cloudflare Workers (compute), Workers KV (cache + session), D1 (tenant database), SSL/TLS termination, DDoS & abuse defense at the edge. AES-256 at rest, TLS 1.3 in transit.
Vercel
Static marketing site (tinkytown.com) and the QR-scan AAC surface (/use.html). No tenant data stored at Vercel; only public marketing HTML + the kiosk runtime bundle.
Stripe
PCI DSS Level 1 service provider. Stripe holds the card-data scope; TinkyTown never sees PAN, CVV, or full card details. Tokenized payment methods only.
Resend
Tenant-facing emails: signup confirmation, deployment ready, billing notices, security disclosures. No visitor data sent through email.
Google Gemini API
Board generation and translation at tenant signup time. Input data sent over TLS. Per Google’s paid-API terms, content sent via the API is not used to train models. Visitor tile-taps are never sent to Gemini at runtime; translations are cached after first generation.
Cloudflare Registrar
tinkytown.com domain registration and authoritative DNS via Cloudflare. DNSSEC enabled.
GitHub
Private repository for application source. Two-factor authentication required on all maintainer accounts. Secret-scanning + Dependabot security alerts enabled.
Google Analytics 4
Aggregate site traffic for the marketing site. No visitor PII, no tile-tap data, no cross-site tracking. IP anonymization enabled. Used only to count "how many people visit the homepage" type questions.
Subprocessor change notice: if we add or change a subprocessor that materially handles tenant data, every active tenant gets a 30-day email notice before the change takes effect. Tenants can object — if we can’t reach an accommodation we’ll honor a no-fault contract exit.
PHI does not flow. By design.
Hospital CMOs, Patient Experience Officers, and hospital Compliance Officers ask about this first — so we lead with the architecture, then the honest gap.
The data-flow design
TinkyTown is built so that Protected Health Information never enters our infrastructure. A hospital patient tapping a tile communicates with the front-desk staff member directly through the patient’s own phone; our servers see the abstract tile event, not the patient.
Concretely, when a patient at a hospital triage counter taps the "I have chest pain" tile in Spanish:
- What our servers see:
tile_tapped: chest_pain @ hospital_X, hour H, lang=es - What our servers do NOT see: the patient’s name, MRN, DOB, room number, insurance ID, date of admission, or any other identifier
- What stays on the patient’s device: the text-to-speech output that the staff member hears, and any custom phrases the patient typed into the phone keyboard
Because no PHI is collected, transmitted, or stored on our side, the HIPAA scope is structurally narrow. This is by deliberate architectural choice, not accident.
The honest gap No standard BAA yet
HIPAA-compliant data flow and a formal third-party HIPAA attestation are not the same thing. We have the former. We do not yet have the latter.
For hospitals that need a signed Business Associate Agreement before contract, we can scope one during the enterprise pilot conversation. We will sign a BAA that reflects the actual data flow described above. This is a one-off agreement today, not a standard-issue document — we flag that honestly.
If your hospital procurement workflow requires a SOC 2 Type II + a separate HIPAA attestation report from an independent auditor, we don’t have those yet. We can include them in the pilot scoping timeline.
FERPA-aligned. By the minimum-collection design.
FERPA (the Family Educational Rights and Privacy Act, 20 U.S.C. § 1232g) protects personally identifiable information from student education records. TinkyTown doesn’t collect any of it.
Why FERPA is structurally satisfied
- No student identifiers collected. We never ask for student name, student ID, date of birth, parent name, address, IEP status, or any other field that constitutes a "directory information" or "education record" item under FERPA.
- Tile-tap data is anonymous. A student at the school front office tapping "I need to see the nurse" produces the same record shape as any other tile-tap: venue + tile + hour + language. Nothing ties that record to the student.
- K-12 schools are on the free tier. Data minimization is the entire deployment philosophy — we don’t need PII to run the product, and we don’t collect it.
Written DPA on request
Schools and districts whose procurement workflow requires a written Data Protection Agreement (DPA) or a "School Service Provider Pledge"-style document can request one at signup. We’ll send a DPA that reflects the actual minimum-collection design above. Email lukekist@tinkytown.com with subject "DPA REQUEST — [your school / district]".
Higher education (FERPA + § 504 + ADA Title II)
Universities are on the enterprise tier and frequently have additional compliance overlays (FERPA + ADA Title II for public institutions, Title III for private; Section 504 for federally-funded; ACAA for campus airports; § 1557 for university health centers). We meet university IT, general counsel, and disability-services offices during the pilot conversation to map the actual surface area of the deployment.
If you find something, tell us.
We’d much rather hear from a researcher who found a bug than from a victim. If you spot a security issue, here’s how to reach us and what to expect back.
How to report
Email lukekist@tinkytown.com with subject line:
SECURITY DISCLOSURE — [your finding]
Include a clear description of the issue, reproduction steps if possible, and any logs or screenshots that demonstrate impact. PGP optional; if you need our public key, ask in the first email and we’ll send it.
What you can expect
- Triage within 48 hours — you’ll get a human reply acknowledging receipt and giving a first-pass severity assessment.
- Status update within 7 days — we’ll tell you what we’ve confirmed, our planned fix path, and a target patch date.
- Coordinated disclosure — we ask for a reasonable embargo before public disclosure. 90 days is the industry norm and we honor that. For critical issues we move much faster; if your timeline differs, tell us in the first email.
- Credit on request — if you want public credit when the fix ships, we’ll add you to the Hall of Fame below. If you want to stay anonymous, we’ll respect that.
Safe-harbor for good-faith research
If you operate in good faith — you do not access more visitor or tenant data than is necessary to demonstrate the issue, you do not modify data, you do not disrupt service, and you give us a reasonable embargo before going public — we will not pursue legal action under the CFAA, DMCA, or state computer-misuse statutes. We treat good-faith research as a gift, not a threat.
Hall of Fame
Honest status: no disclosures filed yet. When the first responsible-disclosure report ships, we’ll publish the researcher’s name (with permission), the rough class of issue, and the patch date here.
Email us. We delete within 30 days.
Tenants own their data. If you want it deleted, you don’t need to log a ticket in a portal, navigate a deletion wizard, or wait on a quarterly review.
How tenant deletion works
- Email lukekist@tinkytown.com with subject "DATA DELETION REQUEST — [your business / venue name]" from the email address on the tenant account.
- Confirmation within 5 business days — we reply with the scope of what will be deleted and a target completion date.
- Deletion within 30 days — tenant database row, deployment configuration, custom board overrides, and contact records purged from production D1. Anonymous tile-tap counts (which contain no identifiers) are retained.
- Subprocessor cascade — we instruct Stripe to delete billing records (subject to Stripe’s legal-retention requirements) and Resend to delete email logs.
- Backups — deleted records are removed from production immediately; backup retention is 30 days, after which the record is unrecoverable.
Visitor data deletion
Because we don’t collect visitor PII in the first place, there’s nothing visitor-identifying to delete. A visitor who taps tiles at a venue counter does not create a record we could surface a deletion request against — their language preference lives only in their own phone’s local storage, and the anonymous tile-tap counter cannot be reverse-mapped to them.
If a visitor still wants comfort, they can clear their browser’s site data for tinkytown.com on their phone and every trace of their session is gone.
Retention
- Active tenant records — retained while the account is active.
- KV cache entries — auto-expire by TTL (translation cache 365 days, session cache hours, board cache 30 days).
- Billing records — retained by Stripe per Stripe’s policy and applicable financial-records law (typically 7 years).
- Anonymous tile-tap counts — retained indefinitely as aggregate analytics with no identifiers.
- No long-term tenant data retention beyond what is necessary for billing, audit, and operational continuity.
Monitored. Notified. Public when warranted.
We run a small operation. Our incident response reflects that — pragmatic, fast, and honest about what monitoring is and isn’t in place.
Active monitoring
- Cloudflare Worker rate limits on every API surface (boards, translate, vision, library sync, auth)
- Abuse triggers on excessive 4xx/5xx rates and on signup-flow anomalies
- 5xx burst alerts — configured at the Cloudflare layer with email paging
- Origin gate on the API surface — only the allowlisted production origins can call the worker; arbitrary referrers are blocked
- SSRF guards on any endpoint that accepts a URL parameter (e.g. business-URL fetch at signup) — private-network and metadata-endpoint addresses are denied
Tenant notification
If we confirm a material security incident affecting tenant or visitor data, every active tenant receives an email notification within 72 hours of confirmation. The notification will include:
- What we know and what we don’t yet know
- Which data, if any, was potentially affected for that specific tenant
- What we’ve done to contain and remediate
- What the tenant should do, if anything
- A point of contact for follow-up questions
If we determine that no tenant data was affected, we still publish an incident note for transparency.
Public status page Not built yet
A public status page at status.tinkytown.com is on the roadmap but not yet built. Today, incident communication is via direct email to affected tenants plus a note in our changelog. When the status page ships, it will display real-time uptime + incident history; until then, expect direct communication.
Honest history
To date, TinkyTown has not had a confirmed material security incident affecting tenant or visitor data. We have run internal security audits and shipped 8 hardening fixes (origin gates, KV failure-mode hardening, XSS sinks, SSRF guards, rate-limit tier upgrades, demo-preview gating, room-deletion ACLs, plus the spatial-room data-isolation hardening) — the changelog is publicly inspectable in the repo. If and when an incident occurs, we’ll add it here with the date and remediation note.
Security questionnaire? Send it.
If you’re an ADA Coordinator, CIO, CISO, General Counsel, Privacy Officer, or Procurement Lead and you have a vendor security questionnaire to send, we’ll fill it out honestly and return it inside one business week.
Ready to start the pilot conversation?
Honest disclosure is the first step. If your IT or legal team needs a deeper conversation, a written DPA, a signed BAA, or a custom timeline to a certification we don’t yet hold — that’s the pilot conversation. Bring your questionnaire.