Tallwright
Log inRequest early access
Developers

Add verifiable evidence to your product without rebuilding your stack.

One SDK call after a consequential action. Commitments are computed in your environment; the content never leaves. Tallwright witnesses checkpoints of your evidence log, and anyone can verify a record against them.

Start here
NodePythonGo
$ npm install @tallwright/sdk

import { Tallwright } from "@tallwright/sdk";
const tw = new Tallwright({ env: "acme/production", key: process.env.TALLWRIGHT_KEY });

// after the consequential action
const r = await tw.record({
  action: "refund.approved",
  ref: "order-88231",
  payload: { amount: "240.00", currency: "EUR" }   // stays local
});
r.commitment   // derived locally; what Tallwright receives
r.verifyUrl    // what your customer receives

The payload is used to compute the commitment in your process and is not transmitted. Get a key by creating your first Environment; the first three are free.

Developer mental model
1 · Your app records

A consequential action becomes a record.

2 · Your environment commits

The record is appended to your evidence log and a commitment is computed, locally.

3 · Tallwright witnesses

Checkpoints of the log are witnessed. A witnessed checkpoint is a point at which Tallwright witnesses the current state of your evidence log.

4 · Customer or third party verifies

Against the witnessed state, on a public page or with the CLI.

How much work is this?

What changes

One call after each consequential action. One Environment per product, customer, deployment or workload. A verification link shown to your customer where the record is shown.

What stays local

Payloads, subject identifiers, free text, your evidence log, and the computation of commitments. Nothing in your data model moves.

What Tallwright handles

Witnessing checkpoints, keeping proof history, serving public verification, exports for offline checks, and the failure states below.

First complete flow.

Environment, record, evidence, verify. Four calls, under ten minutes.

# 1 · Environment: a separate context with its own identity and log
$ tallwright env create acme/production --region eu
env     acme/production
status  ready · identity managed

# 2 · Record: append to the evidence log, commit locally
const r = await tw.record({ action: "refund.approved", ref: "order-88231", payload });

# 3 · Evidence: checkpoints are witnessed automatically; ask for the package
const pkg = await tw.evidence(["order-88231"]);
pkg.coveredBy     // checkpoint witnessed 2026-08-14T10:37:00Z
pkg.url           // hand this over

# 4 · Verify: from the other side, no key
$ tallwright verify ./record.json
result  MATCHES · chain consistent · witnessed 2026-08-14T10:37:00Z
What leaves your system
Commitments

One per record. Fixed size, not reversible.

Metadata

Environment, log position, commit time. What a verifier needs, nothing more.

Never

Payload, subject_id, free text. The SDK has no transport for them.

Environments and identities

Every Environment has its own identity and its own evidence log. Under Cloud Proof the identity is managed by Tallwright. Own Identity, with keys in your KMS or HSM, is coming soon and changes nothing in this flow.

Failure is part of the API.

Every result is one of four, every one is predictable, and nothing fails open. If Tallwright cannot witness, your SDK says so per record; it never pretends.

ResultMeaningWhat you do
witnessed

The record is in your log and a witnessed checkpoint covers it.

Nothing. Show the verification link.

refused

Wrong identity, wrong Environment, or a key without the right scope. Nothing was recorded.

Fix the configuration. The refusal is logged on both sides.

mismatch

A presented record differs from the witnessed state, or the chain is inconsistent.

Treat the record as changed. The verifier sees the same result.

missing evidence

No witnessed checkpoint covers this record yet, or the proof history has expired.

Wait for the next checkpoint, or extend proof history. Never a silent pass.

Verify from the other side.

The public page, the REST endpoint and the CLI all implement the published Verification and Evidence Policy. The CLI runs offline against an export, so a security team can confirm the page is not lying.

# offline, against an export; no network
$ tallwright verify ./record.json --export ./proof-history.json
record     refund.approved · order-88231
covered    checkpoint 2026-08-14T10:37:00Z · acme/production · EU
result     MATCHES · chain consistent

# the same, via REST (public, no key)
POST /v1/verify  { record, environment }
→ { "result": "matches", "witnessedAt": "2026-08-14T10:37:00Z" }

Go deeper.

SDK

Node, Python, Go. Record, evidence, export, webhooks.

SDK reference
API

REST with OpenAPI 3.1. Environments, records, evidence packages, verify, export.

API reference
CLI

Environments, offline verification, exports. Open source.

CLI
Architecture

Evidence log, commitments, checkpoints, witness. The boundary, drawn once.

Cloud Proof
Self-Hosted and Managed

Run Tallwright on your infrastructure. Deployment guides and the standalone witness.

Enterprise
Reference docs

Witness Practice Statement, Verification and Evidence Policy, Retention Policy.

Legal and policies