Learn

The governed-operations skills library.

A public, open curriculum for building systems and making decisions that can be verified rather than trusted. Every skill is published here to read and as a machine-readable file for the models that will read it. Free to read, learn, cite, and apply, with attribution.

Filter the library

Foundations · 01 of 28

Verification over trust

Verification over trust is the practice of accepting a claim only when it resolves to independent evidence — a receipt, a measurement, a source, a hash, an approval, or a reproducible process — rather than to assurance alone.

Also searched as: trustless verification, zero-trust, provenance

What it is

Most operational failures are trust failures: someone believed a figure, a status, or a completion claim that had no evidence behind it. Verification over trust inverts the default. A statement is treated as unproven until it resolves to something checkable, and the check does not require trusting the party who made the claim.

Why it matters

The failure this prevents is quiet and expensive: a figure believed because it was asserted confidently, a status believed because a dashboard was green, a completion believed because someone said done. Each is a trust substituted for a check. The hard part is that verification is more work in the moment and the pressure is always to accept and move on — so the discipline has to be structural, built into how a claim is accepted, not left to whoever is tired that day. Done right, it also changes who you can work with: if the check stands on its own, you no longer need to trust the counterparty, only the evidence.

When to use it

  • A figure, status, or completion is about to be accepted into a decision or a record.
  • A counterparty, vendor, or model asserts a result you are expected to rely on.
  • A dashboard shows green and someone proposes acting on it.
  • An outcome feels settled but no artifact has been pointed to.

Principles

  1. 01A claim is not evidence. Model-said-so, rendered, and committed are not the same as proven.
  2. 02Every accepted claim must resolve to a receipt, measurement, source, hash, approval, or reproducible process.
  3. 03Verification that depends on trusting the vendor is not verification. The check must stand on its own.
  4. 04The absence of evidence is a hold, not a pass.

How to apply it

  1. Step 1Write down the claim you are being asked to accept, in one sentence.
  2. Step 2Name the single piece of evidence that would make it checkable.
  3. Step 3If that evidence does not exist, treat the claim as unproven and hold.
  4. Step 4If it exists, verify it without relying on the word of the party who produced it.
  5. Step 5Record the verification so the next reader does not have to repeat it.

Where it fails

Confidence laundering
A claim is believed because it was stated with authority, and the authority is mistaken for evidence.
Green-light trust
A passing build or a green dashboard is read as proof of correctness, when it only proves the check that ran, not the thing you care about.
Vendor-dependent check
The only way to confirm a result is to trust the party that produced it, so the verification adds nothing.

In practice

A supplier reports a reconciliation as complete and asks for sign-off. The disciplined move is not to argue — it is to name the one artifact that would make the claim checkable: the reconciled ledger with a hash over the inputs and a reproducible procedure. If that artifact exists, it is verified without the supplier in the loop and the sign-off stands on evidence. If it does not, the claim is held as UNVERIFIED and the sign-off waits — not because the supplier is distrusted, but because a record that cannot be checked is not yet a record.

Reference

Accepted evidence types

  • Source citation
  • Uploaded document
  • Hash
  • Receipt
  • Metric
  • Signed approval
  • Reproducible procedure
  • Audit log
  • Observed outcome
  • Independent corroboration

If it cannot be verified, label it

  • UNVERIFIED
  • CONTEXT_ONLY
  • REQUIRES_REVIEW
  • REJECTED

Evidence cost rises with consequence

  • Level 0: casual context
  • Level 1: single source
  • Level 2: trusted source
  • Level 3: multiple corroborating sources
  • Level 4: observed internal evidence
  • Level 5: reproducible and audited
  • High-risk decisions require Level 4 or Level 5

How the loop closes

The claim is linked to its evidence artifact (receipt, hash, measurement, or reproducible run), and an independent party can confirm it without privileged access.

Why it is open

The method is stronger when it is shared.

A discipline that only one company understands is a liability for everyone who depends on it. Publishing the principles — and the machine-readable files that let any model learn them — makes the whole field more verifiable, and makes clear where the work comes from.