Truth Computing

Deployed · Supported by Truth Computing · Affordable Family Vision Center

We built, deployed, and continue to actively support the digital front door for Affordable Family Vision Center.

Truth Computing designed and deployed the public web experience for Affordable Family Vision Center, an independent optometry practice in Montclair, California, led by Dr. Rosali Quintanar, and remains the practice's ongoing engineering partner — the site keeps shipping as the practice's needs change, not a one-time build. The system includes online visit requests, bilingual (English/Spanish) patient-facing content, insurance and payment information, and a separate staff sign-in surface.

Recent work: a real self-pay pricing table and insurance-plan checker, an eyewear catalog organized by category, a full service list, an interactive vision-comparison feature for the homepage, and directions/appointment-request links throughout the site.

The public site and booking workflow are live. Broader clinical workflow automation remains separately scoped and prototype-stage — it is not represented here as a fully deployed clinical product. Browsing the public site does not create a patient record or transmit health information; patient records live in a separate, access-controlled staff system.

  • Live public practice site, continuously supported
  • Online visit-request workflow
  • English / Spanish patient-facing experience
  • Insurance plan checker & self-pay pricing
  • Eyewear catalog by category
  • Interactive vision-comparison feature
  • Separate staff sign-in surface
Construction See statistics →

Two things live here. PreCheck, a presubmittal compliance engine that catches code red lines before a design reaches the city, is in build. The film below is field documentary: how we learned the sector before we built in it.

ConstructionMedia

Urban Sprawl Across California

A field documentary describing urban sprawl throughout California: how unchecked outward development reshapes land, infrastructure, and communities across the state.

2024

Prototype · Haul

Haul is a freight-dispatch prototype built with and for an independent trucking dispatcher or owner-operator.

The prototype focuses on fraud verification, consent-compliant messaging, and cash-flow tooling.

Education See statistics →

Live · Feynman

We built Feynman, a free AI learning platform that rebuilds university-level coursework as a Learning Ladder: the same concept met at five heights, from a kindergarten spark to the real thing, with honest rungs so every student finds a step they can stand on. It is free for first generation and low income students, starting with students in Jurupa Valley and Montclair as the program rolls out. Open Feynman →  Mission, privacy & safety →

Fire Departments See statistics →

Field journalism. Four fires in 2025, reported from the ground.

Fire DepartmentsJournalism

Pacific Palisades Fire

Part one of our wildfire journalism series. A ground level look at the Pacific Palisades fire: how it spread, who responded, and what the community faced.

2025
Fire DepartmentsJournalism

2025 Clay Fire

Part two of the series. A community under threat: documenting the 2025 Clay Fire and the firefighters working to hold the line.

2025
Fire DepartmentsJournalism

2025 Mandalay Fire

Part three of the series. A journalist’s look at the 2025 Mandalay Fire: the conditions on the ground and the response as the blaze moved through the area.

2025
Fire DepartmentsJournalism

Bain Fire, Jurupa Valley

Part four of the series. Reporting from the ground on the Bain Fire in Jurupa Valley: how it spread and the firefighters working to contain it.

2025
Homeless Shelters See statistics →

A field documentary, shot in 2025.

Homeless SheltersJournalism

Homelessness

A field documentary on homelessness: the people, the conditions, and the systems responsible for answering.

2025
High Schools See statistics →

Field journalism from a school board meeting in Chino Valley. Public decisions, reported in public.

High SchoolsJournalism

Chino Valley Unified School District Board Meeting

Field journalism from a Chino Valley Unified School District board meeting, documenting the decisions and debates shaping local schools.

2025
Immigration See statistics →

Field journalism. Nine parts, from Riverside to Tijuana, reported through 2025.

ImmigrationJournalism

Part 1: Riverside, California

Part one of a nine part field journalism series on immigration, reported on the ground in Riverside, California.

2025
ImmigrationJournalism

Part 2: San Diego, California

Part two. Reporting from San Diego, California.

2025
ImmigrationJournalism

Part 3: San Ysidro, California

Part three. At the border crossing in San Ysidro, California.

2025
ImmigrationJournalism

Part 4: 9/11 and the Border

Part four. How 9/11 reshaped border security in a new era.

2025
ImmigrationJournalism

Part 5: June 8 Protest

Part five. Documenting the June 8 protest as the city reaches a breaking point.

2025
ImmigrationJournalism

Part 6: After the Protest

Part six. The aftermath, and Mayor Karen Bass’s response.

2025
ImmigrationJournalism

Part 7: NoKings Protest

Part seven. On the ground at the NoKings protest, June 14, 2025.

2025
ImmigrationJournalism

Part 8: MacArthur Park Aftermath

Part eight. MacArthur Park in the aftermath of the July 10, 2025 response to ICE raids.

2025
ImmigrationJournalism

Part 9: Mexico Finale

Part nine, the finale. Across the border in Tijuana, Baja California, July 2025.

2025
Where we go next Start a conversation →

Eight sectors where the cost of a wrong answer is high enough to justify the work. We are meeting the people who do it and choosing who to build with first. The statistics behind each one are already published.

In selection means we are choosing a partner. No commitment exists yet. When one does, the work appears on this page.

Reliability

We build AI systems that assume the model can be wrong.

Reliability, to us, means the model is never the only thing standing between a prediction and a consequence. This is the operating doctrine behind every deployment above.

AI can be useful without being given unchecked authority. In consequential workflows, Truth Computing separates what a model can suggest from what a system is allowed to do. Models may help read, classify, summarize, prioritize, or draft. When an action could materially affect a person, organization, record, communication, or decision, we design for human review, deterministic safeguards, and an auditable path to the final action.

Reliability is not a promise that software will never fail. It is the discipline of deciding where failure matters most, limiting what automation can do at that boundary, and making uncertainty visible before it becomes consequence.

Principles

Five commitments that hold across every workflow we touch.

These are not industry-specific rules. They are how we decide what a model is allowed to do, whoever the end user is.

  1. 01

    Humans hold the authority

    A model can provide information. That does not automatically give it permission to act.

    For consequential workflows, we prefer systems where a person can inspect, approve, reject, modify, or escalate an AI-assisted output before the irreversible step occurs.

    Depending on the system, a model might summarize a document, identify an anomaly, draft a communication, classify a record, recommend an action, or prioritize a queue — but none of that inherently grants permission to send, publish, approve, disclose, diagnose, transact, or change a protected record.

    Human-in-the-loop is not a magic phrase. A review step is useful only when the human has enough context to understand the recommendation, enough time to review it, the ability to override it, a clear indication of uncertainty, and meaningful responsibility for the final action.

    AI may assist the decision. A human retains authority over the consequence.
  2. 02

    The model does not police itself

    Safety controls should live outside the model whenever they can.

    Asking one AI system whether another AI system behaved safely is not sufficient when the rule can be checked deterministically. We prefer independent mechanisms for things like permission checks, state transitions, source verification, tenant boundaries, signatures, approvals, transmission rules, timing restrictions, data holds, and required human review.

    When a rule can be enforced without asking the model, do not ask the model to enforce it.
  3. 03

    Uncertainty reduces authority

    “I don’t know” should never silently become “go ahead.”

    If a required check fails, a dependency is unavailable, evidence is incomplete, or confidence is insufficient, the system should move toward review, refusal, hold, or escalation — rather than quietly treating uncertainty as permission.

    The less certain the system is, the less authority it should have.
  4. 04

    We protect the boundary where consequence occurs

    Start with the consequence, then work backward.

    Before designing a safeguard, we ask what is the most consequential thing this system can cause to happen — information leaving a protected environment, a communication reaching a person, a recommendation becoming an official decision, one organization’s data appearing in another’s workflow, an automated transaction executing, a finding becoming actionable, an evaluation reaching someone, a claim being published. Then we identify the boundary immediately before that action and put an independent control there.

    The closer a system gets to consequence, the stronger the control should become.
  5. 05

    Every claim states its limit

    Reliability claims need boundaries.

    If we say a control protects something, we should also be able to say what it does not protect. A good technical claim answers: what does this control do, what failure does it reduce, and what remains outside its scope. That means avoiding words like secure, safe, compliant, hallucination-proof, or tamper-proof unless the actual mechanism supports that exact claim.

    • Prefer tamper-evident over tamper-proof.
    • Prefer human review is required before this action over fully human-controlled.
    • Prefer this check verifies the cited passage exists over hallucinations are eliminated.

Human-in-the-Loop

Human authority by design.

Human-in-the-loop should not mean placing an approval button at the end of an automated process. The human has to retain meaningful authority — which means designing the system so the person reviewing an AI-assisted decision can understand what the system saw, what it concluded, what evidence supports that conclusion, what remains uncertain, and what will happen if they approve it.

Context

The reviewer can see the relevant underlying information.

Evidence

The system exposes why it reached the recommendation, where evidence is available.

Uncertainty

The system distinguishes checked, unchecked, uncertain, and unsupported states.

Control

The reviewer can reject, modify, hold, or escalate the recommendation.

Consequence visibility

The reviewer knows what will actually happen after approval.

A Necessary Complement

Human review can fail too.

People can miss warnings, approve too quickly, misunderstand outputs, or become overly reliant on automation. So we do not treat human review as the only safety mechanism. Where the workflow warrants it, we combine human authority with deterministic gates, permission boundaries, source evidence, explicit uncertainty states, audit trails, separation between generation and execution, reversible intermediate states, staged rollout, shadow mode, kill switches, and rate or spend limits.

Stated Plainly

What we do not believe.

More model intelligence automatically produces more reliability.

A more capable model can still operate outside its evidence or make an inappropriate recommendation.

A confidence score is the same thing as certainty.

Confidence can be useful, but it does not replace evidence or independent verification.

Another model is always an adequate safety layer.

Where deterministic verification is possible, we prefer it.

Human review automatically makes a system safe.

Human oversight needs context, authority, and a well-designed escalation path.

Automation should expand simply because it performs well on average.

The cost of being wrong matters as much as the average accuracy.

A successful test proves the absence of failure.

Tests show that specific expected behaviors worked under specific conditions.

A security or reliability control should be described more strongly than it behaves.

If something is tamper-evident, we call it tamper-evident. If it is planned, we call it planned.

Architecture

A common pattern.

This general flow underlies most of what we build, regardless of industry.

  1. AI assists

    The model reads, classifies, summarizes, drafts, or recommends against the input.

  2. Independent checks

    Permissions, evidence, policy, state, timing, and limits are verified outside the model.

  3. Human review where consequence warrants it

    A person can approve, modify, reject, or escalate.

  4. Execution boundary

    Only authorized actions proceed past this point.

  5. Audit record

    What happened, when, and under which conditions is recorded for later review.

In Practice

How this appears in practice.

Privacy Posture · prototype

Local-first, where that’s the design.

For local-first research prototypes, the query path runs on-device and content stays on the machine except for optional, explicit online sync. This describes a privacy posture for those specific systems, not a universal guarantee across every Truth Computing product.

What we do and don’t publish, as a general policy:

  • Public boundary. We do not publish client, patient, account, candidate, vendor, private meeting, or internal financial identifiers unless a separate explicit review clears that material for public use.

Failure Modes

We design across four layers, not one.

We try to design controls across all four layers rather than assuming one layer can compensate for all the others.

Model failure

The AI produces something wrong or unsupported.

System failure

The surrounding application executes incorrectly.

Human failure

A reviewer misunderstands, overlooks, or over-trusts the system.

Organizational failure

A process, configuration, integration, or deployment is wrong even though the code behaves as written.

In Closing

What reliability means to us.

Reliability is not the claim that a system cannot fail. It is the practice of making consequential failure harder to reach, easier to detect, easier to interrupt, and easier to understand afterward.

We want models to be useful. We do not want usefulness to be confused with authority. Where the consequence warrants it, humans retain the decision, deterministic systems enforce the boundary, and the record should make it possible to understand what happened. And when a control has a limit, we should be the first people to tell you what it is.

  • Assume the model can be wrong.
  • Keep humans in authority over consequential decisions.
  • Enforce critical rules outside the model.
  • State the limits of every control as clearly as the control itself.