Truth Computing

Truth Computing

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.

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.