Doctrine & Verification Philosophy

The Proof Standard

Proof over rented trust. Verification standards and release principles for software forged at The Proof Foundry.

The standard, in brief

  • Every public download ships with a published SHA-256 checksum.
  • Every release claim is tied to a recorded qualification result.
  • Every boundary is stated — including what a checksum does not prove.

What follows is the doctrine behind those three lines.

Core Trust Philosophy

"Proof over rented trust."

No fake claims. No missing receipts. Ship with proof.

If it matters, keep the receipt.

The Proof Standard is our studio engineering commitment: software claims are backed by measured empirical evidence and published checksums rather than adjective-heavy marketing or unverified promises.

Windows distribution note: Unsigned by Windows. Receipt-backed by Proof Foundry.

Verification Principles

The Seven Principles of Proof

How we measure, document, and publish software release evidence.

1. Claim only what was measured

Release claims are tied strictly to named execution gates and empirical test passes. We do not use vague marketing adjectives to describe release readiness.

2. Identify the exact artifact

Every downloadable binary asset is bound to its canonical filename and its 64-character hex SHA-256 cryptographic digest.

3. Publish checksums where artifacts exist

When a file is offered for public download, its SHA-256 checksum is published alongside it so builders can verify byte-identity before running the file.

4. Separate trust dimensions

We explicitly distinguish artifact identity, evidence custody, publisher signing, platform reputation (SmartScreen), runtime gate passes, and security claims.

5. Candidate proof != release authority

A successful build candidate or internal test pass does not create public release authority. Candidates on hold remain clearly labeled as unreleased.

6. Record known limitations

Every product publishes its known boundaries and operational constraints so users understand exact capabilities before installation.

7. Keep reproducible evidence for independent verification

Where verification records, test counts, manifests, or release receipts are published, use open/readable formats and enough identifying context to show which artifact and which claim the evidence covers.

Honest Boundaries

What a Checksum Proves (and What it Does Not)

  • SHA-256 match = byte-identity verification. It proves your local download is byte-for-byte identical to our published build artifact.
  • Checksum match is NOT malware certification. Digest matching confirms integrity against our published manifest, not a third-party security audit.
  • Unsigned status & Windows SmartScreen: Some Proof Foundry Windows builds are distributed unsigned. SmartScreen may warn when a downloaded file or publisher does not yet have established reputation. That warning is a Microsoft reputation signal; it does not by itself establish that the software is malicious or safe. Verify the published artifact identity and review the product's disclosed behavior and limitations.
  • SmartScreen reputation & receipts: Microsoft SmartScreen uses its own reputation signals, including file/hash reputation and publisher/signing reputation. Proof Foundry receipts are a separate evidence system; neither substitutes for the other.

Information Architecture

Navigating Proof & Support

Proof Standard

The doctrine and verification philosophy governing how we build, test, and publish software.

Release Records

Release records, checksums, test gate counts, and cryptographic evidence receipts for every product.

Public Truth

Machine-readable public truth — deterministic JSON records generated from the same release facts. Their human-readable layer is the Truth Files.

Support Hub

Practical installation, SmartScreen handling, APK verification commands, and problem reporting templates.