Truth Computing · System
Truth Computing Health
Status: Prototype · Last updated: date not published (see Known Limitations) · Design partner: Affordable Family Vision Center (Dr. Rosali Quintana)
Problem
Practice growth & operations for independent family optometry.
A practice growth and operations platform for independent, value-positioned family optometry practices, built for a named design partner: Affordable Family Vision Center.
Research Question
Where can AI assist without ever bypassing a clinician?
Where can AI assist intake, imaging workflows, and clinical documentation while a clinician still reviews every output before it enters the record.
Architecture
A spine, four modules planned on top of it.
The system is built as "Spine v0": a cross-cutting foundation (data model, classification, automation controls, consent, audit trail) that four modules (Marketplace, Client Acquisition, Client Retention, Schedule) are meant to sit on. Of those four, only Client Acquisition (the funnel, a grounded client brief, and a Frame-Wall frame recommender) is built so far; Schedule, Marketplace, and Retention are schema-only — the database has a table for each, but no route or job writes to them yet.
Reliability controls built into the spine (see the Reliability page for how this maps to our public CLINICAL_HOLD language):
- Three-bucket escalation-only triage. Every message is classified ROUTINE / SENSITIVE / CLINICAL. Classification can only ever escalate toward CLINICAL — a mislabeled clinical message cannot be downgraded.
- The CLINICAL_HOLD invariant. A clinical message is never auto-sent under any automation posture and can only be released by an optometrist (OD). It is enforced through the automation-mode matrix (Review All / Review Sensitive Only / Full Automation), an independent check in the send pipeline itself, and the delivery step — though see Known Limitations below on that last one.
- TCPA per-channel consent gating. An electronic message to a known patient never sends without a stored, granted consent for that specific channel.
- Tamper-evident, hash-chained audit log. Append-only; any edit or deletion of history is detected by re-walking the chain. This is a separate control from CLINICAL_HOLD enforcement itself — it logs what happened, it does not gate what happens.
Models / Components
STRICT SQLite, bilingual human-approved templates.
Every core entity (practice, staff, patient family/patient, appointment, order, membership, recall, referral, review request, message event, audit) is a STRICT SQLite table with CHECK constraints and foreign keys, so the database itself rejects invalid data. Message templates are bilingual (English/Spanish), pre-authored, and never machine-translated.
Data Boundary
No unconfirmed facts published to the public site.
Every public-site page reads its content (hours, phone, staff bios, insurance list, stocked eyewear brands) from a per-section content store rather than hardcoded copy; a section nobody has confirmed yet renders a labeled "pending confirmation" placeholder instead of a guessed value. The public Eyewear page never surfaces the codebase's browsable shop catalog, which is synthetic demo data, not this practice's real stock. Analytics are first-party only: page views and CTA-button clicks, no IP, cookie, or visitor identity.
Evaluation
Evaluation in progress.
The repository's own test suite (76/76 passing at last commit reviewed) covers CLINICAL_HOLD, the audit chain, RBAC, and consent gating. No clinical outcome evaluation, accuracy figure, or benchmark score for this system has been published, and none should be inferred. The strabismus-detection computer-vision research listed on our Research page is a separate, disclaimed research project and is not a diagnostic capability of this system.
Human Authority
Only the optometrist can release a clinical message.
Role-based access control is least-privilege; only the OD (optometrist) role can release a message held at CLINICAL_HOLD. Front-desk, optician, and admin roles cannot.
Failure Modes
Known, not yet built, and gated features.
The Schedule module (appointment reminders, confirmations, waitlist, no-show analytics) is not yet built and needs an SMS/WhatsApp provider (10DLC registration) before it can send anything for real. Marketplace (bundle pricing, financing) needs a financing partner relationship. Retention (recall engine, membership billing) and the referral/review-request part of Acquisition are gated on legal review of anti-kickback and FTC exposure before they go live. None of these are stubbed with fake logic that could silently misbehave — they are simply not built yet.
Security
No third-party runtime web dependencies.
The server is Node's built-in http; passwords are scrypt with per-user salts and constant-time verification; sessions are server-side, HttpOnly + SameSite=Strict; every state-changing POST requires a CSRF token (double-submit, constant-time); strict CSP, nosniff, DENY framing, no-referrer on every response; login is rate-limited; all SQL uses bound prepared statements. We do not claim HIPAA compliance for this system.
Reliability Controls
See Architecture, above.
The CLINICAL_HOLD invariant, consent gating, and audit trail described above are this system's reliability controls; we don't repeat them here.
Known Limitations
The delivery step is a faithful stub.
The patient-message delivery adapter is a deliberate stub: nothing is actually sent to a patient today; the pipeline, review gate, consent gate, and audit trail around it are real. Separately, a staff-facing notification (an email to staff when a new booking/contact form is submitted, via SendGrid) has been built and committed to the repository locally, but as of our last review it had not yet been pushed to the remote or deployed — it is blocked on confirming a verified sender address and on the user running the deployment steps themselves. This staff notification is distinct from the patient-facing delivery adapter and is not gated by CLINICAL_HOLD, since it never contains a patient message. We do not claim HIPAA compliance anywhere in this system's description.
Release History
Not independently dated in this session.
We could not independently verify commit dates for this system's own repository from the Truth Computing website repository in this session. See the homepage Shipping Log for dated events we could verify.
Artifacts
What's public today.
The public practice website at affordablefamilyvision.com. This system's description on the Systems page and the Research page.